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1 DETAILED ACTION 

2 

3 All objections and rejections not set forth below have been withdrawn. 

4 Claims 1 - 3, 6 - 8, 10 - 18, 20, 22, and 23 are pending. 
5 

6 

7 Specification 

8 

9 The specification is objected to as failing to provide proper antecedent basis for 

1 0 the claimed subject matter. See 37 CFR 1 .75(d)(1 ) and MPEP § 608.01 (o). Correction 

1 1 of the following is required: Claim 3 comprises the limitation "wherein the fragmenter 

1 2 module does not split the IKE data packets unless no response to a previously-sent IKE 

1 3 data packet has been received". The Applicant has not pointed out where the amended 

14 claim is supported, nor does there appear to be a written description of the claim 

1 5 limitation in the application as filed. 
16 



1 7 Claim Rejections - 35 USC §112 

18 

19 The following is a quotation of the first paragraph of 35 U.S.C. 112: 

20 The specification shall contain a written description of the invention, and of the manner and process of 

2 1 making and using' it, in such full, clear, concise, and exact terms as to enable any person skilled in the 

22 art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 

23 set forth the best mode contemplated by the inventor of carrying out his invention. 
24 

25 Claim 3 is rejected under 35 U.S.C. 112, first paragraph, as failing to comply 



26 with the written description requirement. The claim contains subject matter 
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1 which was not described in the specification in such a way as to reasonably 

2 convey to one skilled in the relevant art that the inventor(s), at the time the 

3 application was filed, had possession of the claimed invention. See above 

4 objection to the specification. 
5 



6 Claim Rejections - 35 USC § 103 

7 

8 The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

9 obviousness rejections set forth in this Office action: 

10 (a) A patent may not be obtained though the invention is not identically disclosed or described as set 

1 1 forth in section 102 of this title, if the differences between the subject matter sought to be patented and 

1 2 the prior art are such that the subject matter as a whole would have been obvious at the time the 

1 3 invention was made to a person having ordinary skill in the art to which said subject matter pertains. 

1 4 Patentability shall not be negatived by the manner in which the invention was made. 

15 

16 Claims 1-3,6-8,10-18,20,22 and 23 are rejected under 35 U.S.C. 103(a) as 

1 7 being unpatentable over Thread Topic (TT), "RE: CERT_REQ_PAYLOAD usage", 



1 8 in view of Jinmei, "How to write UDP/lpv6 applications that care about path MTU", 

1 9 in view of Kent et al. (Kent), "Fragmentation Considered Harmful". 

20 

21 Regarding claim 1 , TT discloses the generating and transmitting an IKE packet 

22 over a network (TT, pg. 1 , par. 1-3). TT discloses that the problems with unintentional 

23 fragmentation occur when IKE payloads are encapsulated within singular, large UDP 

24 packets, which can be subsequently fragmented (TT, pg. 1-2, par. 7). TT teaches to 

25 avoid fragmented IKE payloads and suggests for IKE applications incorporate path 
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1 discovery so as to reduce the size of IKE payloads that will be encapsulated within UDP 

2 packets (TT, pg. 4, par. 1-4; pg. 7). 

3 TT does not appear to explicitly state that, an IKE application, as a result of 

4 discovering the MTU, should fragment a packet into a plurality of packets, i.e. 

5 fragmenting the IKE packet into a plurality of smaller packets and transmitting each of 

6 the plurality of smaller packets over a network. 

7 However, Jinmei teaches that an application, such as IKE, can discover the path 

8 MTU and subsequently avoid fragmentation by dividing a single packet into a plurality of 

9 smaller packets (pg. 2, 3). 

1 0 It would have been obvious to one of ordinary skill in the art to recognize 

1 1 teachings of Jinmei along with the teachings of TT. This would have been obvious 

12 because one of ordinary skill in the art would have been motivated to implement a 

13 mechanism so as to avoid unintentional fragmentation. 

14 The combination enables fragmenting IKE packets according to an appropriate 



15 before creating or encapsulating the packets as IKE payloads within UDP. However, 

1 6 IPSEC does not appear to specifically state known methods of packet fragmentation, 

17 such as conditions requiring fragmentation and that a packet fragment should have a 

18 proper packet header. 

19 Kent et al. discloses principles for packet fragmentation. While Kent discusses 

20 these principals of packet fragmentation often in the context of the IP layer (Kent, pg. 

21 75, par. 4), Kent further discloses that these fragmentation methods are to be applied in 

22 higher protocol layers as well. Upper level protocol layers should be cognizant of 
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1 fragmentation issues, and should fragment or send smaller packet sizes if the it is 

2 known that a larger packet size will be fragmented at the IP layer (Kent et al., section 3, 

3 par. 4). For example, Kent discloses that an upper layer (i.e. TCP) should not send a 

4 large un-fragmented segment when it a lower layer (i.e. IP) will have to fragment it 

5 (Kent, pg. 79, pars. 3, 4). 

6 Kent discloses that the packet fragmentation method consists of fragmenting a 

7 larger packet into a plurality of fragments. Each fragment is sent as a separate packet, 

8 with each of the plurality of smaller packets containing a properly formatted header 

9 according to the protocol (Kent et al., section 2.1 ). 

10 It would have been obvious to one of ordinary skill in the art to employ the 

1 1 principles for packet fragmentation disclosed by Kent with the teachings of the 

1 2 combination of TT and Jinmei requiring the fragmentation of IKE packets. This would 

1 3 have been obvious because one of ordinary skill in the art would have been motivated 

1 4 to practically implement packet fragmentation methods for the purpose of fragmenting 

1 5 IKE packets so as to avoid creating large UDP packets as taught by the combination of 

16 TT and Jinmei. 

1 7 Therefore, the combination enables: 

1 8 determining whether a response to the IKE packet was received and 

1 9 fragmenting the IKE packet into a plurality of smaller packets when a response is not 

20 received (Kent et al., section 3.3, pars. 1 - 3). To avoid improper fragmentation at the IP 

21 layer, the combination of IPSEC and Kent et al. discloses that a transmitting host would 

22 choose whether to fragment an IKE packet using received acknowledgements ("a 
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1 response") of successful packet transmission. If the host does not receive an 

2 acknowledgment ("a response") then it will have to fragment it's transmitted packets into 

3 smaller packets until it receives a successful transmission acknowledgment, and 

4 accordingly discovers the proper fragment length for transmitting packets. 
5 



6 Regarding claim 2, the combination enables: 

7 wherein each header includes an identifier that may be used to associate the 

8 smaller packet with a corresponding IKE packet (Kent et al., section 2, par. 4, lines 1 -8; 

9 section 2.1, par. 2 ) 
10 

1 1 Regarding claim 3, it is rejected, at least, for the same reasons as claim 1 , and 

1 2 furthermore because the combination enables: 

1 3 a User Datagram Protocol (UDP) stack that is capable of generating UDP data 

14 packets for transmission over a network (TT, pg. 1-2, par. 7; pg. 4, par. 1-6). 

1 5 an IKE protocol stack that generates IKE data packets that are subsequently 

16 processed by the UDP protocol stack (TT, pg. 7; pg. 1-2, par. 7; Jinmei, pg. 2); 

1 7 and a fragmenter module that intercepts IKE data packets prior to being 

1 8 processed by to the UDP protocol stack and splits the IKE data packets into a plurality 

1 9 of smaller data packets that may be subsequently formatted by the UDP protocol stack 

20 (TT, pg. 7; Jinmei, pg. 2). The combination enables fragmenting IKE packets (thus a 

21 fragmenter module) prior to being processed by the UDP stack. 
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1 wherein the fragmenter module does not split the IKE data packets unless no 

2 response to a previously-sent IKE data packet has been received (Kent et al. , section 

3 3.3, pars. 1 - 3). Herein, the combination enables that once a suitable response is 

4 received, the fragmenter module does not continue to split the data packets. 

5 and wherein, each of the plurality of smaller data packets includes a header 

6 formatted according to the IKE protocol (see rejection of claim 1 ). 
7 

8 Regarding claim 6, the combination enables: 

9 receiving a plurality of fragments of an IKE data packet from a transmitting node, 



1 0 wherein each fragment includes an identifier that associates each fragment with an IKE 

1 1 data packet ; and discarding all fragments that contain a first identifier if a 

1 2 predetermined number of fragments are received that contain a second identifier (Kent 

13 et al., section 2.4, par. 3); 

14 and determining the total size of all fragments that contain the same identifier 

15 and discarding said fragments when the total size exceeds a predetermined limit (Kent 

16 et al., section 2.4, par. 2, 3). Herein, the combination discloses that a fragment ) 

1 7 reassembly process may not progress if the total size of a datagram (comprising 

18 fragments with a same identifier) exceeds a predetermined limit. As an example, a 

1 9 sufficiently sized space for reassembling a large datagram could comprise a size of 8 

20 buffer spaces. Thus, when that predetermined limit is achieved, the occupying 

21 fragments of an unassembled datagram will expire and be discarded. 
22 
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1 Regarding claim 7, the combination of enables: 

2 wherein the step of discarding all fragments that contain a first identifier is 

3 performed when at least one fragment is received that contains a second identifier (Kent 

4 et al., section 2.4, par. 3). 
5 

6 Regarding claim 8, the combination enables: 

7 determining whether all fragments that are associated with an IKE data packet 



8 have been received, and sending a no acknowledgment (NAK) message to the 

9 transmitting node when at least one fragment has not been received (Kent et al., section 

10 3.3.3). A receiving host is disclosed as making a determination as to whether all 

1 1 fragments associated with an IKE packet has been received. The receiving host will 

12 convey a "Time exceeded" message ("NAK") to the transmitting host when at least one 

1 3 fragment has not arrived, indicating to the transmitting host that it has not received all 

14 the fragments. 
15 

16 Regarding claim 10, the combination does not appear to explicitly state wherein 

17 the predetermined limit is 64 kilobytes. This, however, would have been obvious to one 

1 8 of ordinary skill in the art to set a predetermined limit of 64 kilobytes as the total size of 

1 9 all possible fragments. As evidenced by the "Glossary for the Linux FreeS/WAN 

20 project" - (definition for DoS), this would have been obvious to one of ordinary skill in 

21 the art because the standardized size limit of an IP packet is 64 kilobytes, and a failure 
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1 to discard illegitimate packets when the size exceeds the standard limit would result in 

2 denial of service attacks. 
3 

4 Regarding claim 1 1 , it is rejected, at least, for the same reasons provided for the 

5 rejection of claims 1 and 2, and furthermore because the combination discloses that to 

6 avoid unnecessary fragmentation of packets (Kent, section 3.2), the system should be 

7 cognizant of network timing issues. Thus, a system will not assume it is necessary to 

8 retransmit a packet until a determined period of time ("round-trip time" or the estimated 

9 time period between a sender's packet transmission and a sender's reception of a 

1 0 packet acknowledgement response)(Kent, section 3.2. 1 ). 

1 1 While the combination does not nominally recite "a timer", it would have been 

1 2 obvious to one of ordinary skill in the art to employ appropriate timing means ("a timer") 

13 for determining when packet retransmission is necessary. This would have been 

1 4 obvious because one of ordinary skill in art would have been motivated by the 

1 5 combination's teachings for measuring and determining timing delays before 

16 retransmitting previously transmitted packets within a system. 
17 

1 8 Regarding claim 1 2, the combination enables: 

1 9 further comprising means for determining the capability of the receiver node for 

20 receiving fragmented packets (Kent et al., section 3.3, par. 2). 
21 
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1 Regarding claims 13, 14, and 15 they are rejected, at least, for the same reasons 

2 as claims 1 and 2. 
3 

4 Regarding claim 16, the combination enables: 

5 wherein the plurality of smaller packets contain the same information as that 

6 contained within the original IKE packet (Kent et al., section 2.4, par. 3, section 2.1 ). 
7 

8 Regarding claim 17, the combination enables: 

9 wherein at least one of the plurality of smaller packets contains the header 



1 0 formatted according to the IKE protocol (Kent et al. , section 2. 1 ). As disclosed by the 

1 1 combination, fragmentation involves fragmenting the original packet into smaller 

1 2 packets, each containing the protocol and header fields of the original packet. 
13 



14 Regarding claim 18, it is rejected, at least, for the same reasons as claims 1 and 

15 11, and furthermore because the combination enables: 

1 6 wherein the steps of generating, determining and fragmenting are performed 

1 7 independently of performing any steps on the data packet corresponding to a transport 

1 8 layer protocol and/or a network layer protocol (Jinmei, pg. 2). The combination of 

1 9 enables generating and fragmentation (accordingly determination to fragment) as 

20 occurring before the lower protocol layers. 
21 
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1 Regarding claim 20, it is rejected, at least, for the same reasons as claims 1 and 

2 11, and further because the combination enables: 

3 fragmenting the packet into a plurality of fragments using a code module that 

4 does not implement the TCP, UDP or IP protocols before the packet is processed by a 

5 code module that does implement the TCP, UDP or IP protocols ( Jinmei, pg. 2; TT, pg. 

6 7; Kent et al., section 3). The combination enables fragmentation which is application 

7 based and therefore inherently performed by some type of module for instructing a 

8 computer ("code module"). 

9 comprising including an identifier that identifies the data packet in each packet 

1 0 fragment (see rejection of claim 2); and transmitting the packet fragments over a 

1 1 network (see rejection of claim 1 ). 
12 

13 



14 Claims 22 - 23 are rejected under 35 U.S.C. 103(a) as being unpatentable 

1 5 over the combination of TT, Jinmei, and Kent in view of Cerf et al. (Cerf), "A 

16 Protocol for Packet Network Intercommunication". 

17 

18 Regarding claim 22, the combination enables: 

19 receiving a plurality of fragments of a single IKE data packet, wherein the 

20 fragments were transmitted from a transmitting node in an order that can be determined 

21 from information contained within the received data fragments (Kent et al. ; section 2. 1 , 
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1 par. 3; section 2.4, par. 3). The combination does not disclose that a receiver may 

2 detect duplicate packets from a single IKE packet and then discard such duplicates. 

3 Cerf discloses that a receiver which receives duplicate packets will discard such 

4 duplicates. Additionally, Cerf discloses that a receiver may detect out of order packets, 

5 and choose to store and acknowledge such packets or discard such packets (Cerf, pg. 

6 7-8, "Retransmission and Duplicate Detection"). It would have been obvious to one of 

7 ordinary skill in the art to detect and discard duplicate packets. This would have been 

8 obvious because one of ordinary skill in the art would have been motivated to avoid 

9 resource consummation by superfluous data. 
10 

1 1 Regarding claim 23, the combination discloses sending a message to the 

1 2 transmitting node that out of order packets have been received (Cerf, pg. 7-8, 

13 "Retransmission and Duplicate Detection"). 
14 

1 5 Response to Arguments 

16 

17 Applicant's arguments with respect to the pending claims have been considered 

1 8 but are moot in view of the new ground(s) of rejection. 

19 Applicant's arguments filed 6/7/07 have been fully considered but they are not 

20 persuasive. Specifically, applicant asserts that the recitation "wherein the fragmenter 

21 module does not split the IKE data packets unless no response to a previously-sent IKE 

22 data packet has been received' is supported by the original disclosure. However, the 
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1 examiner points out that the applicant has not shown support for the recitation of not 

2 splitting IKE packets unless no response is received, nor does there appear to be a 

3 written description of the claim limitation in the application as filed 
4 

5 Conclusion 

6 

7 The prior art made of record and not relied upon is considered pertinent to 

8 applicant's disclosure. 

9 See Notice of References Cited 
10 

1 1 A shortened statutory period for reply is set to expire 3 months (not less than 90 

1 2 days) from the mailing date of this communication. 

1 3 Any inquiry concerning this communication or earlier communications from the 

1 4 examiner should be directed to Jeffery Williams whose telephone number is (571 ) 272- 

15 7965. The examiner can normally be reached on 8:30-5:00. 

16 If attempts to reach the examiner by telephone are unsuccessful, the examiner's 

17 supervisor, Emmanuel Moise can be reached on (571) 272-3865. The fax phone 

1 8 number for the organization where this application or proceeding is assigned is (703) 

19 872-9306. 
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Information regarding the status of an application may be obtained from the 



2 Patent Application Information Retrieval (PAIR) system. Status information for 

3 published applications may be obtained from either Private PAIR or Public PAIR. 

4 Status information for unpublished applications is available through Private PAIR only. 

5 For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 

6 you have questions on access to the Private PAIR system, contact the Electronic 

7 Business Center (EBC) at 866-21 7-91 97 (toll-free). 



9 Jeffery Williams 
10 AU:2137 
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